1. Field of the Invention
This invention relates to authentication protocols.
2. Description of the Related Art
Authentication protocols are used in communication networks to enable one entity in the network to satisfy another entity of its capacity to be provided with a service, for example the undertaking of a data transaction or the granting of access to a resource. For example, if a user's mobile telephone is to access an e-mail account on a remote server then the server may wish to authenticate the mobile phone so that it can be sure that it is making the contents of the account available to the correct entity. Similarly, the user of the mobile phone may want the phone to authenticate the server so that he can be sure that data that he provides to the server is not being intercepted by a third party who might be impersonating the server.
A number of authentication protocols have been developed.
The Extensible Authentication Protocol (EAP), described in [RFC2284], provides a standard mechanism for support of multiple authentication methods. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. Specific EAP/SIM and EAP/AKA methods have been defined for the purposes of the OWLAN system, which makes use of the GSM or UMTS authentication methods for the authentication of WLAN access and derivation of link keys for the protection of the WLAN link.
EAP is a general authentication protocol, designed to allow end-points to use multiple forms of authentication. EAP does not require the server (typically a PPP or IEEE 802 end-point) to authenticate the client itself, rather it allows the server to proxy authentication messages to a back-end authentication server, and inspect the packets to determine if the authentication was successful.
One of the goals of EAP is to enable the development of new authentication methods without requiring the deployment of new code on the local authentication server. As a result, the local server acts as a “passthrough”, and need not understand specific EAP methods.
Since its deployment, a number of weaknesses in EAP have become apparent. These include lack of protection of the user identity or the EAP negotiation and no standardized mechanism for key exchange. For example, EAP/SIM and EAP/AKA solve these problems by making use of the specific features of SIM and USIM (AKA) authentication methods.
Recently IETF working groups have designed three new protocols to develop standard solutions. Two of them PEAP and TTLS, originating from the pppext working group, are intended to solve the same problem as EAP/SIM and EAP/AKA, but independently of the specific EAP method. The idea in brief is to encapsulate the EAP protocol within TLS. The third protocol PIC is developed by the ipsra working group, and it develops a unilateral version of the ISAKMP authentication and key derivation protocol, within which the EAP protocol is encapsulated. All three protocols include a method of managing secret parameters for further use. In PEAP and TTLS keys are derived from the TLS master key, while in PIC the tunnel derived by simplified ISAKMP is used to transport security association from the local authentication server to the client.
By wrapping the EAP protocol within TLS, Protected EAP (PEAP) claims to provide user anonymity and built-in support for key exchange.
FIG. 1 shows the relationship between the EAP peer (client), the network authentication server (NAS) and the backend authentication server. As described in the figure, the EAP conversation “passes through” the NAS on its way between the client and the backend authentication server. While the authentication conversation is between the EAP peer and the backend authentication server, the NAS and the backend authentication server need to have established trust for the conversation to proceed.
In PEAP, the conversation between the EAP peer and the backend server is encrypted and integrity protected within a TLS channel, and mutual authentication is required between the EAP peer and the backend server.
As a result, the NAS does not have knowledge of the TLS master secret derived between the EAP Peer and the backend authentication server, and cannot decrypt the PEAP conversation. In order to providing keying material for link-layer ciphersuites however, the NAS does obtain the master session keys, which are derived from the TLS master secret via a one-way function.
Since EAP methods may not know the link layer ciphersuite that has been negotiated, it may not be possible for them to provide link layer ciphersuite-specific keys. In addition, attempting to provide such keys is undesirable, since it would require the EAP method to be revised each time a new link layer ciphersuite is developed. As a result, PEAP derives master session keys, which can subsequently be truncated for use with a particular link layer ciphersuite. PEAP does not discuss the format of the attributes used to communicate the master session keys from the backend authentication server to the NAS; examples of such attributes are provided in [RFC2548].
The operation of PEAP is as follows:
1. Establish TLS connection. The TLS record protocol provides a secure connection between the peer and the back-end authentication server
2. Authenticate TLS server. The TLS handshake protocol is used for server authentication
3. Authenticate user. The user of the peer authenticates by tunnelling another EAP mechanism (e.g. Generic Token Card) inside the EAP-TLS connection. The back-end authentication server may have to contact another server to get the user authentication information validated.
4. Generate session keys. Using the TLS Pseudo-Random Function (PRF), the peer and the back-end server generate key material for use between NAS and peer.
5. (Transport session keys). The session key is transported from the server to the authenticator using e.g. Radius attributes and secure connection.
In a new internet draft, draft-buckley-pppext-eap-sim-gmm-00.txt, an application of PEAP to GSM authentication is presented. The architectural overview of this EAP method using SIM is depicted in FIG. 2.
The architectural view of EAP-TTLS is essentially the same as in PEAP, see FIG. 3. EAP-TTLS claims to allow legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other cryptographic attacks.
EAP-TTLS also allows the client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between the client and server based on the TLS handshake.
When record layer security is instantiated at the end of a TLS handshake, a pseudo-random function (PRF) is used to expand the negotiated master secret, server random value and client random value into a sequence of octets that is used as keying material for the record layer.
EAP-TTLS leverages this technique to create keying material for use in the data connection between client and access point. Exactly the same PRF is used to generate as much keying material as required, with the constant string set to “ttls keying material”, as follows:
EAP-TTLS_keying_material=PRF(SecurityParameters.master_secret, ttls keying material”,
SecurityParameters.client_random+SecurityParameters.server_random);
The master secret, client random and server random used to generate the data connection keying material must be those established during the TLS handshake. Both client and TTLS server generate this keying material, and they are guaranteed to be the same if the handshake succeeded. The TTLS server distributes this keying material to the access point via the AAA carrier protocol.
The PIC protocol is a method to bootstrap IPsec authentication via an “Authentication Server” (AS) and user authentication mechanisms (e.g., RADIUS), see FIG. 4. The client machine communicates with the AS using a key exchange protocol where only the server is authenticated, and the derived keys are used to protect the user authentication. Once the user is authenticated, the client machine obtains credentials from the AS that can be later used to authenticate the client in a standard IKE exchange with an IPsec-enabled security gateway. The later stage does not require user intervention.
The PIC protocol realizes this approach and secures it using simplified ISAKMP and IKE mechanisms. The protocol embeds EAP messages [RFC2284] in ISAKMP payloads to support multiple forms of user authentication. Once this user authentication succeeds, the client machine obtains from the AS credentials that can later be used by the client to perform regular IKE authentication with an IPsec-enabled gateway. PIC defines several forms of credentials and can be extended to support others. Note that this document uses the term “credentials” for both digital certificates and shared secret keys.
PIC requires no modification to IKE. Instead it uses simplified elements of ISAKMP and IKE to obtain a much less ambitious goal than general IKE, namely the secure provisioning of credentials for successfully authenticated users. The direct use of IKE, e.g. as compared to TLS tunneling [GETCERT], reduces complexity and contributes to the efficiency of the protocol.
The PIC protocol is defined between the Client and the AS. All other exchanges between the entities are implicit in the protocol. This applies in particular to user and machine authentication between the AS and the Back-End Authentication Server, and certification between the AS and the CA.
The four main stages of the proposed PIC protocol are:
1. An optional round of messages provides partial protection of the AS from denial-of-service attacks by verifying that the initiator of the exchange is reachable at the purported source IP address. This is done before any significant CPU or memory resources are consumed by the AS.
2. The protocol establishes a one-way authenticated channel from the client to the AS in which only the server is authenticated.
3. User authentication is performed over this secured channel. User authentication information is transported using EAP tunnelled within ISAKMP.
4. The AS sends the client a (typically short-term) credential, which can be used in subsequent IKE exchanges. This credential can be thought of as a certificate, or a private key generated or stored by the AS and accompanied by a corresponding certificate. It may also be a symmetric secret key, or other information for deriving such a key.
In stage 4 the created ISAKMP tunnel is used to obtain the secure provisioning of credentials for successfully authenticated users.
Another alternative proposal is HTTP digest authentication within a TLS tunnel, which is not described in detail here.
It should be noted that the network entity called “back-end server” in the description of PEAP, see FIG. 1, has not at all the same role in the authentication protocol as the back-end server in PIC has. The PEAP back-end server is called the EAP Server in FIG. 2 and its role is essentially the same as that of the TTLS AAA server of EAP-TTLS (FIG. 3) and the AS of PIC (FIG. 4).
The above proposals all utilise an inner client (or mutual) authentication protocol within a secure tunnel constructed using a session key resulting from an outer server authentication protocol. In the following description we use EAP/AKA as an example of the inner protocol. But the general points of the discussion are applicable to any pair of authentication protocols used in the above manner. This is convenient because the EAP/AKA protocol is to be implemented by the USIM of 3G mobile stations, and so this protocol is readily available to a terminal that is to be authenticated. EAP/AKA is a challenge-response protocol. In the protocol the “responding entity” which is to be authenticated shares a secret key with the “challenging entity” which is to verify its authenticity. The challenging entity issues to the responding entity a challenge message which includes challenge data, which is typically randomly generated data. The responding entity then generates response data by applying a known function to that challenge data and to the secret key. The response data is returned to the challenging entity in a response message. The challenging entity can also apply the known function to the challenge data and the key, and the result of that can be compared to the response data. Only if the two match is the responding entity is authenticated. In the above proposals the authentication method of AKA is to be used in just the same way as in its pre-existing applications: i.e. the terminal is supplied with challenge data to which it is to apply the function, and then it returns the result to the network for authentication. However, the key agreement part of UMTS AKA is not used.
In place of the EAP encapsulated AKA protocol any EAP type protocol can be used for authentication of the terminal to network.
FIG. 5 illustrates the logical architecture that is common to all of the above proposals. First, a stage-one authentication exchange 40 takes place. In that exchange the identity of a back-end server 41 is authenticated to a terminal entity 42. However, the identity of the terminal entity is not authenticated to the back-end server. Then a stage-two authentication exchange 43 takes place, in which it is intended that the terminal entity is authenticated to the back-end server. Since each of the proposals is intended to be compatible with existing terminal entities, the existing authentication protocol (e.g. EAP/AKA), which has hitherto been usable as a stand-alone protocol, is used for the essential authentication part of stage two. In stage two the back-end server issues a challenge 44 to the terminal entity. The challenge is of such a type that the back-end server can (either by itself or through referral to a further authentication server) authenticate the terminal by means of its response to the challenge. The terminal entity processes the challenge and formulates its response (step 45) and returns that response to the back-end server (step 46). Then the back-end server checks the response (or refers it for checking) (step 47). If the response is correct then the back-end server has authenticated the terminal entity and can issue it with credentials, e.g. session keys that allow it to carry out subsequent secure transactions with the server (step 48). Otherwise no such credentials are issued and the terminal entity cannot carry out such transactions.
Some of the stage-two protocols have both authentication function and key-agreement function. In existing proposals the key-agreement function of the stage-two protocol is not used. Instead, the session keys are derived using the key-agreement function of the stage-one authentication protocol.
Up to now it has been supposed that the above proposals provide for secure authentication of both the back-end server and the terminal entity to each other. However, the inventors of the present invention have observed that this is not the case.
The vulnerability of the above proposals will be described with reference to FIG. 6. In FIG. 6 like items are numbered as for FIG. 5. In FIG. 6 a “man-in-the-middle” (MITM) attacker 49, who intends to impersonate a terminal entity 42, takes the place of the terminal entity in FIG. 5. The MITM performs the stage-one authentication with the back-end server. Then during the stage-two authentication when it receives the challenge message (step 44) from the back-end server it forwards it on to the terminal entity 42. (Step 50) Using the pre-existing AKA protocol, it returns the appropriate response to the MITM. (Step 51). Then the MITM forwards that response to the back-end server. (step 46). Since the response is the correct response for authentication of terminal entity 42 the back-end server will authenticate the MITM as terminal entity 42 (step 47) and issue it with credentials accordingly (step 48). That may allow the MITM access to supposedly secure services, impersonating the identity of terminal entity 42.
The proposals described above have been developed with the aim of using the existing challenge-response protocol for the essential authentication part of stage two, since that is already a feature of the terminals that are to use the system. Since the proposals fail to provide adequate security, a new approach is needed.